Hi Ray,
If the probe motion completes without the probe ever triggering this is considered an error and GCode execution is "Stopped" which causes Mach3 to turn off the Spindle.
If you do not like this behavior there is an undocumented method for you to handle probe errors on your own in Mach3 VB code. Change the status from 0 to 3 while probing. This informs the Plugin to not handle any error if the motion completes. Instead it just places the status into DRO 1100 and allows execution to continue. So the status codes reported from the Probe.c program become:
0 - Probe is inactive (waiting for Probe signal)
1 - Error Probe was already active before we started
2 - Probe detected - hardware feedhold activated - Captured positions ready for upload
3 - Probe is inactive (waiting for Probe signal) don't stop if motion completes - set result status and continue on.
VB code after the G31 may check DRO 1100 for a value of either 2 (success) or 3 (failure)
Regards
TK
| Group: DynoMotion |
Message: 2207 |
From: himykabibble |
Date: 11/13/2011 |
| Subject: Re: Mach3 & G31 |
Tom,
Hmmmm.... doesn't seem to work here. I changed the "flag = 2" in the while loop to "flag = 3" (this is in NotifyProbeMach3.c), and the behavior is exactly the same. I don't really care, but seems odd for G31 to be doing that. Is that to allow auto-probing tool length on-the-fly?
Other than that, probing now seems to be working OK. It is important to set the PROBE input in Mach3, as well as in KFlop, since most Mach3 probing macros will check the probe state before starting by just reading the raw input, and abort if so, to make sure the probe isn't already active.
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
> Â
> If the probe motion completes without the probe ever triggering this is considered an error and GCode execution is "Stopped" which causes Mach3 to turn off the Spindle.
> Â
> If you do not like this behavior there is an undocumented method for you to handle probe errors on your own in Mach3 VB code.  Change the status from 0 to 3 while probing. This informs the Plugin to not handle any error if the motion completes. Instead it just places the status into DRO 1100 and allows execution to continue. So the status codes reported from the Probe.c program become:
> Â
> 0 - Probe is inactive (waiting for Probe signal)
> 1 - Error Probe was already active before we started
> 2 - Probe detected -Â hardware feedhold activated -Â Captured positions ready for upload
> 3 - Probe is inactive (waiting for Probe signal) don't stop if motion completes - set result status and continue on.
> Â
> VB code after the G31 may check DRO 1100Â for a value of either 2 (success) or 3 (failure)Â Â Â
> Â
> Regards
> TK
> Â
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, November 13, 2011 8:56 AM
> Subject: [DynoMotion] Mach3 & G31
>
>
> Â
> When I use Mach3, and do a G31 via MDI, but the probe does not trigger, an "M5" is sent to the Mach3 status line, and the following appears on the KMotion console:
>
> Mach3 Notify Message=4, Direction= 0, Spindle Set to 0.000000
> Spindle Stop
>
> This is coming from the spindle notify handler. Why is a G31 doing *anything* to the spindle??
>
> Regards,
> Ray L.
> |
|
| Group: DynoMotion |
Message: 2209 |
From: Tom Kerekes |
Date: 11/13/2011 |
| Subject: Re: Mach3 & G31 |
Hi Ray,
The way the C program is written the variable "flag" is only a C Program local variable to remember if we ever looped waiting for the probe. Then the flag is only put in the global persist variable 56 AFTER the probe becomes active and the while loop exits (which of course never happens in the case we are considering). So you must add:
persist.UserData[56]=3;
Before the while loop.
Actually looking at the NotifyProbeMach3.c I see there was a bug introduced way back in 12/11/2009. An attempt to expand probing from XYZ to XYZABC was made. So the status flag after the captured data was described as being moved down to make room for 3 more values (from var 56 to 62). But the change was never fully implemented in the Plugin or even in this code. It looks like it will still work correctly as a XYZ probe which is probably why nobody complained. It should be fixed to work with 6 axes but that would require Users to modify their Probe code on the next revision. We didn't think this through and make it a symbolic define...
TK
| |
